Field of the Invention
The present invention relates to improved security for computer systems. More specifically, the present invention relates to a system and method for processor-based security.
Related Art
Security of data is a very important in today's modern computer systems. So-called “trusted computing” represents a type of computer security that has gained recent interest. The Trusted Computing Group (TCG) industry consortium has defined standards for trusted computing platforms and applications. These include a hardware security chip called the Trusted Platform Module (TPM), which can be added to the motherboard of desktop and mobile computers. Software running on the CPU of a TPM-enhanced computer can request trusted computing services from the TPM chip, chief amongst which are referred to as sealed storage and attestation. Both of these services require the software stack corresponding to an executing piece of software to follow the TPM's measured boot procedure, where a cryptographic hash (measurement) computed over each layer of software launched is sent to the TPM chip.
In sealed storage, the TPM binds integrity measurements of a software stack to a key encrypting a set of data. Following a computer reboot, the key (and the data) can only be retrieved if current measurements of the software stack sent to the TPM chip match the measurements the key was bound to initially. In attestation, the TPM “signs” the software stack measurements it receives to create an attestation report, i.e., a report which identifies all software modules for which access has been requested by a remote party. This report can also include a computation result produced by the software stack, and can then be sent to a remote party to prove the identity of the software running on the platform and certify it produced a given computation result.
TPM-based approaches suffer from security vulnerabilities (e.g., the Cold Boot and TPM reset attacks) as well as performance, scalability and usability issues. Performance is very low, e.g., some operations take several hundred milliseconds, which is unacceptable in modern processors with sub-nanosecond processor cycle times. Scalability is limited, e.g., only a limited number of separate software contexts can be measured concurrently into the TPM. Limited resources and low performance are due to the TCG's goal of producing a very low cost security chip. It is also rather difficult to use TPM-based approaches—programming the TPM is not only unfamiliar but also relatively complex, which may partially explain the notable lack of adoption in software applications, despite being included on the motherboard of newer notebook computers. Several of these shortcomings of TPM-based trusted computing are believed to be due to implantation on a slow, low-cost chip that is separate from the main processor chip.
The security of TPM-based approaches relies on several assumptions that have proven easy to break when attackers have physical access to the platform they are targeting. The TPM threat model assumes that physical memory is secure: that RAM chips and buses cannot be physically probed to insert or extract data and they cannot be tampered with to alter their contents. Based on this assumption, cryptographic keys protected by TPM's sealed storage mechanism are written in plaintext to memory whenever the TPM determines the prevailing software stack has the same integrity measurements. Cold Boot attacks show that with very low-tech equipment costing only a few dollars, an attacker with physical presence can freeze the memory chip to increase its remanence. This gives the attacker time to scan the entire memory, and steal the plaintext keys still persisting in the memory chips. The Cold Boot exploit demonstrated that this technique could recover the root key used in disk encryption systems like Microsoft Vista's BitLocker.
Another assumption is that the TPM chip's reset signal is synchronized with the CPU chip's reset signal. Synchronization ensures that software stack measurements stored by the TPM are only wiped out from the TPM chip when the CPU's software stack is itself wiped out, on a CPU reset. In practice, most TPM chips are connected to Personal Computers (PCs) via the Low-Pin Count (LPC) bus. As demonstrated in the TPM reset attack, the reset signal on this bus can easily be “spoofed” by a physical attacker, without triggering a CPU reset. This allows the attacker to load a malicious software stack, reset the TPM to wipe out traces of this stack and then feed the reset TPM with measurements of a trusted software stack, as if this stack was currently in control of the CPU. To do so, the attacker in control of the malicious software stack can simply send to the TPM a set of measurements corresponding to the trusted software stack, previously recorded on a platform actually hosting such a software stack. These measurements include the identity of a trusted BIOS, OS loader and OS, as if they had been measured and sent to the TPM by the layers of software that are successively loaded upon a CPU reset. In reality, no CPU reset occurred: the measurements are fed successively to the TPM by an attacking program in the already fully booted malicious software stack.
A crucial assumption of the TPM threat model is that the Core Root of Trust for Measurement (CRTM)—also called the Static Root of Trusted (SRTM)—, which is located in a computer system's basic input-output system (BIOS), cannot be tampered with. Tampering with the CRTM allows breaking the security of TPM sealed storage and attestation in the many scenarios where the CRTM is responsible for bootstrapping the measurement procedure. An attacker with physical presence can de-solder the BIOS chip from the motherboard and replace it with a BIOS chip containing a malicious CRTM. Also, simpler methods have been used to successfully tamper with the CRTM with a software-only attack. The Dynamic Root of Trust for Measurement (DRTM) implemented on certain platforms (e.g., Intel TXT) can mitigate the effects of CRTM corruption, although practical attacks on the DRTM have been shown to be feasible.
The fixed amount of TPM registers for storing measurements limits the number of software contexts that can be measured separately and stored in the TPM. Similarly, its simple I/O interface prevents it from handling more than one session at a time (one session is a set of I/O transactions transferring the data and commands necessary to complete a specific security function). These limits on the TPM's scalability have been addressed by the development of a virtualized TPM, able to spawn multiple virtual, software TPMs. The credentials of the hardware TPM are used to vouch for the software TPMs. A Virtual Machine Manager (VMM) running on the platform's processor hosts TPM virtualization logic which gives each Virtual Machine (VM) hosted by the VMM the illusion that they have access to their own TPM. While the virtual TPM allows each software context (i.e., each VM-based software stack) to have access to TPM services independently, it cannot provide these services to software contexts smaller than a VM (e.g., to a software library running within the VM). Each context must contain its own software stack, including an operating system sophisticated enough to host a virtual TPM driver. This limits the number of different contexts that can be handled by a virtualized TPM on a given machine, since each context requires allocating memory and CPU resources for a software stack.
The TPM approach is better suited for platforms hosting a simple operating system, since this is more easily inspected for correctness, and tested for security vulnerabilities. Once it is determined to be trustworthy, its identity can be bound to an initial set of critical data (e.g., cryptographic keys) using TPM's sealed storage. Before providing such an OS with more critical data, a remote party requests a TPM attestation report and simply checks that the OS identity has not changed. However, most PCs today run large, complex, extendible and frequently updated commodity operating systems. Inspecting such an OS for correctness is a very daunting task, as evidenced by the large number of exploitable vulnerabilities found in mainstream operating systems, even long after their release. This means it is practically impossible to determine with certainty that a given commodity OS is trustworthy. TPM-based systems can seal security-critical data to this operating system's identity, but there are no guarantees that the OS will not be hijacked and leak or corrupt the data.
Even if a trustworthy version of the OS is found, its identity would be subject to constant change over time, due to updates, extensions (e.g., a new device driver) and modifications to its configuration data (e.g., new values in the Microsoft Windows registry). It is thus very unlikely that a fixed set of measurements can be found to seal a “trusted” commodity OS to a piece of security-critical data with the TPM. Without such a fixed set, TPM-sealed data must be migrated a priori from one configuration to the next every time a single bit of OS code or data changes.
As a result of its design goal for a low cost chip, the TPM has little computational power and a slow interface to the LPC (Low Pin Count) bus of a processor to which it is interfaced. Each security operation with the TPM requires a sequence of command and data transactions to be transferred via this slow bus, and many operations require the TPM chip to carry out public or private key operations with its limited resources. This leads to very high overheads for TPM security operations, reported to be in the hundreds of milliseconds, an eternity when compared to modern high-throughput general-purpose processors. There is thus clearly a significant performance advantage to be gained from moving trusted computing operations from a low-resource chip to the high-performance processor chip. Not only the CPU has a much greater computational power, it also has direct access to memory data that it may need to decrypt, encrypt, hash, sign or otherwise process as part of trusted computing operations.